Coffman deadlocks in SCOOP

In this paper we address the deadlock detection problem in the context of SCOOP – an OOprogramming model for concurrency, recently formalized in Maude. We present the integration of a deadlock detection mechanism on top of the aforementioned formalization and analyze how an abstract semantics of SCOOP based on a notion of “may alias expressions” can contribute to improving the deadlock detection procedure. Introduction. In this paper we are targeting SCOOP [8] – a concurrency model recently provided with a formalization based on Rewriting Logic (RL) [7], which is “executable” and straightforwardly implementable in the programming language Maude. Our aim is to develop a (Coffman) deadlock [2] detection mechanism for SCOOP applications. Intuitively, such deadlocks occur whenever two or more executing threads are each waiting for the other to finish. Our contribution. We present the integration of a deadlock detection mechanism on top of the formalization in [8]. We also briefly analyze how a simplified, abstract semantics of SCOOP based on a notion of “may alias” expressions [4, 1] can be exploited in order to improve the deadlock detection procedure. The literature on using static analysis [5] and abstracting techniques for (related) concurrency models is considerable. We refer, for instance, to the recent work in [3] that introduces a framework for detecting deadlocks by identifying circular dependencies in the (finite state) model of so-called contracts that abstract methods in an OO-language. The integration of a deadlock analyzer in SCOOP on top of Maude is an orthogonal approach that belongs to a more ambitious goal, namely the construction of a RL-based toolbox for SCOOP programs including a may alias analyzer, as thoroughly presented in [1] and a type checker. Deadlock detection in SCOOP. The key idea of SCOOP is to associate to each object a processor, or handler (that can be a CPU, or it can also be implemented in software, as a process or thread). In SCOOP terminology, objects that can run on different processors are separate from each other. Assume a processor p that performs a call o.f(a1, a2, . . .) on an object o. If o is declared as “separate”, then p sends a request for executing f(a1, a2, . . .) to q – the handler of o (note that p and q can coincide). Meanwhile, p can continue. Moreover, assume that a1, a2, . . . are of “separate” types. In the SCOOP semantics, the application of the call f(. . .) will wait until it has been able to lock all the separate objects associated to a1, a2, . . .. This mechanism guarantees exclusive access to these objects. Processors communicate via channels. In the context of SCOOP, the deadlocking problem reduces to identifying whether a set of processors reserve each other circularly. This situation might occur, for instance, in a Dining Philosophers scenario, where both philosophers and forks are objects residing on their own processors. Given a processor p, by W (p) we denote the set of processors p waits to release the resources p needs for its asynchronous execution. Orthogonally, by H(p) we represent the set of The research leading to these results has received funding from the European Research Council under the European Union’s Seventh Framework Programme (FP7/2007-2013) / ERC Grant agreement no. 291389.